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Abstract 


The NASA Space Network (SN) consists of 
several geosynchronous communications 
satellites, in addition to ground support 
facilities. Space Network management must 
predict years in advance what network 
resources are necessary to adequately satisfy all 
SN users. Similarly, users of the Space 
Network must know throughout all stages of 
mission planning and operations to what extent 
their communication support requirements can 
be met. NASA, at the Goddard Space Flight 
Center, performs Space Network and Mission 
Modeling using The Network Planning and 
Analysis System (NPAS), to determine the 
answers to these questions. 

Introduction 

The Network Planning and Analysis System 
(NPAS) is a deterministic modeling tool that 
accepts either generically or specifically stated 
communication support requirements. Using 
its own scheduling and orbital determination 
software, the NPAS produces an operationally 
valid schedule. Analysis software can then 
generate a variety of reports such as the 
percentage of satisfaction for users, or the total 
utilization of the SN. Analysts can view 
schedules graphically allowing them to identify 
conflicts easily. 

Detailed in its approach, the NPAS can model 
such difficult problems as antenna blockage and 
support requirements based on the physical 
position of a user satellite. The tool can also 
model such factors as the effect of solar 


radiation on the spacecraft and the 
radio-frequency interference between users. 
Also, the NPAS is not limited to the NASA 
Space Network alone. Given the necessary 
information, it can model other space based 
communication networks, as well as 
ground-based networks, both foreign and 
domestic. 


NASA has used the various versions of NPAS 
successfully over the past 15 years as a tool in 
analyzing Space Network loading. The NPAS 
has also changed with the times. It has recently 
been ported to a Unix-based workstation and 
has a new X-window graphical user interface. 
Currently, efforts are in place to develop a 
neural network application for the NPAS. This 
application could be used to obtain an instant 
response to many questions that arise during 
the planning of communication support for new 
space missions. 


Overview of the Space Network 

Modeling with the NPAS atGSFC is applied to 
NASA’s Space Network (SN) . The space- 
based portion of the SN is referred to as the 
Tracking and Data Relay Satellite System 
(TDRSS). The TDRSS consists of five 
geosynchronous Tracking and Data Relay 
Satellites (TDRS), two of which are currently 
operational at 41° W and 174° W. Two others 
are held in reserve and the fifth, the oldest and 
least capable satellite in the network, is 
dedicated to support of the Compton Gamma 
Ray Observatory. 

Only low earth orbiting spacecraft can make use 
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of the SN. These users can communicate with 
a TDRS at K-band using one of two Single 
Access (SA) antennas or at S-band using SA 
or Multiple Access (MA) Ground-station 
limitations restrict the number of MAR users to 
to about five per TDRS. Even though each 
TDRS has only one MAF, the SA resource, 
due to its heavy use, is by far the most 
constrained TDRSS resource. 

It is the job of the NPAS to determine how this 
network will perform in the future under 
changing conditions. 

Modeling SN Loading 

Modeling different aspects of SN loading with 
the NPAS proceeds along two lines. Space 
Network Modeling and Mission Modeling. 
In theory, SN Modeling methods hold user 
requirements constant and vary network 
resources. This is contrasted by Mission 
Modeling techniques which hold network 
resources constant and vary user requirements. 

Analysts perform SN Modeling by determining 
what combination of TDRSS resources and 
mission priorities result in the best overall 
performance of the SN on a yearly basis. They 
make recommendations to NASA management, 
who then decide what course to adopt. These 
formally approved NPAS models are called 
baseline models and used as starting points for 
further studies. Using such approved 
baseline models, analysts perform Mission 
Modeling. Usually the requests come from 
management of new or prospective mission 
projects, or from management of existing 
mission projects that are contemplating changes 
to communications support requirements. 
During the course of mission modeling analysts 
produce variant models that reflect some 
change, or a collection of changes, to a 
baseline model. End products of Mission 
Modeling are termed standard models to 
differentiate them from true baseline models. 

Regardless of the modeling method selected, 
analysts interact with the NPAS software in the 
same way, defining network resources, 
mission requirements, and evaluating resulting 
schedules. 


Obtaining Model Parameters 

The model parameters used by the NPAS can 
be divided into two parts, scheduling and 
coverage. Scheduling parameters include 
information about mission support 
requirements. Examples include minutes of 
support needed per orbit and the minimum 
separation between contacts. Coverage 
parameters deal with the geometry between 
user spacecrafts and network resources. 
Locations of the TDRS, the orbital elements of 
the user spacecraft, and information relating to 
the blockage of the user antenna are examples 
of such parameters. 

The process of collecting user parameters is 
conducted in advance of actual modeling. This 
serves to reduce the needed during modeling to 
acquire needed information. 

Capabilities of the NPAS 

Once the modeling requirements have been 
gathered, the analyst can prepare to input the 
parameters into the NPAS. The number of 
steps required in this process is dependent upon 
the type of study being performed and 
similarities between the new requirements and 
existing baseline, variant, or standard models. 
Often times, minor modifications can be made 
to an existing model to analyze the new 
requirements. 

Usually, the first step taken by an analyst is to 
define the support network. The support 
network can consist of SN or ground-based 
stations, and is referred to as the “network 
model.” 

Then, missions that would be users of the 
defined network for the year being studied are 
modeled. The combination of orbital and 
coverage parameters of the spacecraft with the 
scheduling requirements of the mission is 
referred to as the "mission model" for the 
particular mission. 

Once the network and all appropriate mission 
models are created for the year being studied, 
coverage data is generated for each mission at 
each station. From this coverage data, and 
subject to any constraints defined in the 
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network and mission models, a schedule for 
each mission and each station can be generated. 

This schedule can then be analyzed using a 
number of applications included in the NPAS 
package. Various mission and station report 
analyses can be requested, and a facility exists 
that allows an analyst to examine graphically 
the schedule and certain coverage events. 

Modeling the Network 

A network model in the NPAS can consist of 
stations, physical antennas, services, and 
crews. Hardware limitations, such as TDRS 
interface channels, may also be modeled. 

SN and ground-network stations can have their 
locations specified in a number of ways. In 
particular, SN TDRS locations can be specified 
as either fixed or moving. In the former case, 
only the longitude and the height of the TDRS 
need to given. In the latter, orbital elements for 
the TDRS are specified by the analyst. 

When creating the network model, the analyst 
has the ability to define constraints, such as 
service availability times and fixed down times. 
Other special-purpose constraints, such as 
allowing scheduling to occur on no more than 
six out of eight SA antennas simultaneously, 
also may be modeled. Events such as planned 
maintenance also are easily modeled. 

These features allow the analyst to define real- 
world support network situations. Some 
examples might include TDRS' that arc 
damaged or are otherwise not fully-functional. 

In the course of analyzing SN loading using 
baseline models, the number of single-access 
(SA) antennas available at each TDRS is 
modified often, and the NPAS Modeling Tool 
interface was designed to ease this process. 

Defining Coverage Parameters 

Embedded within the NPAS is a complete orbit 
and coverage generation system which uses a 
modified GTDS to generate station visibility 
data with accuracy to the nearest second. 
Additionally, a facility exists to accept 
externally-generated orbit data. 


An NPAS analyst defines the basic orbital 
parameters of a spacecraft using Keplerian 
orbital elements. Other options exist that allow 
more complex orbit models to be created from 
this point. An example of such a model may be 
one that uses impulsive orbital maneuvering, 
thrust, or transfer orbits. Further modifications 
to the spacecraft orbit can include gravitational 
solar and drag forces. 

A number of mission-specific coverage events 
may also be calculated. Some of these mission- 
specific events include mission apogee and 
perigee points, ascending and descending 
nodes, spacecraft or subpoint sun events, land, 
water, and user boundaries. These events may 
be calculated in the coverage event generation 
and would normally be used for scheduling 
options in the schedule parameters portion of 
the mission model. 

Many missions in the loading studies 
performed using NPAS include mission- 
specific events to direct the mission scheduling. 
One of these missions is Landsat, which 
specifies a number of user and earth boundaries 
over which to schedule. Also, this and other 
spacecraft may only want to schedule when the 
spacecraft or the Earth sub-point is in sunlight, 
and this may be modeled using the mission- 
specific events. 

As another coverage parameter, the analyst also 
can apply an antenna mask to the spacecraft, 
and define the spacecraft attitude and antenna 
orientation. Spacecraft masks are defined for a 
small number of missions in the most recent set 
of baseline models. The effects of masking on 
individual spacecraft has been extensively 
analyzed in variant and standard models for 
some missions, including EOS and the Space 
Station. For the latter mission, a number of 
masks reflective of the various "build" stages 
were modeled. 

Options exist to determine separation angle 
events between a spacecraft and the sun or 
another spacecraft. Here, the angle apex may 
be located at either the spacecraft or the station, 
and the station may be either SN or ground- 
based. Separation angle events have been used 
in the past in variant models in which mutual 
interference between spacecraft was analyzed. 
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Figure 1- Sample Schedule Request 


Defining Schedule Parameters 

Tasks to be performed by each mission are 
modeled as schedule requests in the NPAS. A 
schedule request is simply a request for a 
service, or set of related services, of some time 
duration, to be scheduled over a set of stations. 
Each request is subject to a number of 
constraints that can be imposed by the network 
model, the given request, and other schedule 
requests. Additionally, some constraints, like 
mission pre-pass and post-pass times at various 
relay stations, can be applied to all the requests 
of a single mission. 

Each schedule request is given a priority 
number by the analyst and is subsequently 
scheduled in "highest priority first" order. 
Requests for different missions may be 
intermixed to allow scheduling of all missions' 
critical requirements before any other 
requirements, if this is desired. The current 
practice, however, is to schedule all requests 
for any individual mission together, 
and place the missions into priority order. 


Most schedule parameter modeling in the 
NPAS is accomplished using generic schedule 
requests. A generic request does not specify an 
exact time at which the defined service or set of 
related services is to be scheduled. 
Additionally, the request is typically repeatable 
over periods that extend across the schedule 
span. 

Furthermore, using a generic request, an 
analyst can specify a variable length service 
contact time, in which shorter contact times, 
down to a minimum, can be accepted if the 
maximum length contact cannot be scheduled. 

One mission that is modeled in NPAS using 
generic requests is TRMM. The primary 
request is one 20-to-14 minute S-band forward 
service, with concurrent S-band return service, 
event per orbit. Only one generic request 
would be required in the NPAS to model this 
requirement. 

In the above example (Figure 1), the TRMM 
requirement was for two concurrent services, 
repeatable over the schedule span. Whenever 
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two or more services need to be related in some 
manner and scheduled repeatedly over the span, 
a Prototype Event (PE) structure is defined in 
the generic request. A PE is best viewed as a 
"template" for defining a variety of complex 
relationships between desired services. 

There are a number of options and constraints 
that an analyst can model in each schedule 
request in order to accurately represent the 
request in NPAS and to emulate real-world 
situations. One of these options is the mission 
antenna masking toggle. This allows the 
schedule request to use, or not use, the mission 
antenna mask specified in the coverage 
parameters for the mission. This toggle is 
useful in determining the net effects of blockage 
on the spacecraft visibility. 

A multi-mission shared resources option allows 
a number of selected spacecraft to communicate 
simultaneously over one physical antenna. This 
option could be used to model situations in 
which the Space Shuttle and its payload can 
communicate simultaneously on the same 
TDRS link. 

Many other options exist as well, including 
dynamic rescheduling, in which selected 
higher-priority requests can be removed from 
the schedule if the invoking request did not 
attain a given satisfaction. Once the other 
requests are removed from the schedule, the 
invoking request is rescheduled, and the 
requests which had been removed are 
scheduled following. 

Other special scheduling options include station 
and station antenna schedule preferences, 
forced-handover and hybrid support, and 
maximum elevation priority scheduling. 

Some constraints might include a minimum or 
maximum separation between services, or 
scheduling windows, which define repeatable 
periods in which to schedule. Scheduling can 
also be directed around mission-specific events, 
such as when the spacecraft is in sunlight or 
when passing over a desired land mass, for 
example. The request can be directed to 
schedule when these events occur, or they can 
be directed to avoid scheduling at these times. 
Other mission-specific events include any that 


were defined in the coverage parameters for the 
mission. 

Schedule Algorithm Summary 

Three of the more commonly used schedule 
algorithms in the NPAS are the standard PE, 
standard non-PE, and geometric optimization 
algorithms. 

Before any request is processed by these 
algorithms, the set of available time on 
individual station and mission antennas is 
generated. This set, referred to in NPAS 
documentation as "freetimes," consists of the 
mission visibility at each station with any time 
scheduled by previously scheduled requests 
removed. Additionally, any station or station 
antenna or service downtimes, as well as 
mission-oriented station service suppressions, 
would be removed from this set. 

The standard PE and non-PE algorithms select 
events to schedule from this set using the 
aforementioned priority scheme in which higher 
priority requests are scheduled before lower 
priority requests. Further event scheduling is 
performed on a longest-prime-service-length- 
first, first-come, first-served basis. 

The geometric optimization (GO) algorithm is 
similar to the standard algorithms, but the major 
difference is that this algorithm determines a 
large number of suitable schedules for each 
request and chooses the one that maximizes the 
total scheduled time for the request. In GO, an 
initial greedy schedule is determined’ by 
selecting the local-optimal solutions from 
partitions of the schedule span. If the total 
scheduled time of this solution is less than the 
predicted maximum, then a backtracking 
process is invoked in which the schedule is 
reevaluated using local-sub-optimal solutions 
from one or more partitions. 

Post-Schedule Analyses 

There are a number of applications available in 
the NPAS that allow an analyst to prepare 
different types of reports from the schedule 
results. For example, it is possible to create 
reports of utilization of service types, antennas, 
and frequencies. Analysts can also generate 
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Figure 2 - Sample NPAS Schedule 





Figure 3 -Results from TRMM Study 
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reports of mutual interference between 
spacecraft. Communication channel loading 
can also be analyzed using an NPAS report 
application. F 

One of the more frequently used analysis tools 
is the NPAS Resource Plotter (RPLOT). 
RPLOT allows an analyst to view a mission's 
or station's schedule graphically in an X- 
Windows display. A wide range of options 
exists for examining mission- or station-related 
data, where different types of objects to be 
plotted appear in different colors. Mission- 
related data includes raw station antenna 
visibility and mission-specific events, such as 
apogee or a spacecraft-in-sun condition. 
Station-related data includes station antenna and 
service schedules. An example of an RPLOT 
display appears below in Figure 2. 

Recent Work 

As examples of our work, we have two recent 
mission studies performed for the Tropical 
Rainfall Measuring Mission (TRMM) and the 
Earth Observing System (EOS) projects. 

The TRMM project will be launched in 1997 
and will downlink data at 2 Mbps in real-time 
during its 20 minute S A events. Since ground 
terminal equipment (known as the MDM) limit 
the total downlink bandwidth to 6 Mbps, there 
was a concern whether or not the TRMM 
would experience data loss. Analysis using the 
NPAS took into account the downlink rates of 
all 1997 SN users, and showed that there is 
little to no probability that such data loss would 
occur. It also showed that loads on the terminal 
equipment follows an exponential distribution. 
Results are shown in Figure 3. We have also 
recently provided the EOS project with a 
projected schedule of the their EOS-AM1 
spacecraft as modeled in 1998. This 
information will assist them as they size the 
needed on-board solid-state memory. 

Future Directions 

We are currently exploring aspects of artificial 
intelligence to help speed parts of SN 
Modeling. SN modeling can be a time 
consuming process. We are now developing a 
neural network application that, once properly 


trained, could be used to achieve instant 
responses to specific loading and user 
satisfaction questions. The application would 
be trained by automating numerous database 
modifications, generating schedules, and then 
collating and preparing the data. 

NPAS is a changing modeling system that has 
adapted itself to the environment that it is 
designed to model. It has served NASA well 
over the years and will continue to play an 
important role in the analysis of Space Network 
loading. 
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